ILL – Interlibrary Loans

1 Introduction[//]

This document provides workflow and background information on the handling of Interlibrary Loan Requests. Please see the help of AFO 821 for functional information and the help of AFO 822 for parameter information, as well as the Preferences help for information on configuring the WebOpac.

A note on wording – in this document we refer to Requests made against some other library as outgoing requests, and requests that are made on "our" copies as incoming requests. This all sounds reasonable, except of course, whilst the request is outgoing, the book is incoming, so it is quite possible to get confused.

Other terminology – we have attempted to use the wording that matches that used in the formal ISOILL protocol documentation. Thus "client" represents the person or organisation for whom the item is being requested, whilst "requester" is the requesting library. Notwithstanding, the documentation refers to "reservation" (rather than ISO10160's "hold") since this is the wording used on the existing Vubis displays.

1.1 Overview[//]

System Description

This section aims to give an overview of the ILL module, and a description of the processes and workflow within the module i.e. it attempts to put the module into context.

The Interlending module is designed to handle both incoming and outgoing ILL requests. It is fully integrated with the rest of the system and all related data is available, in appropriate contexts, to all parts of the system.

In addition to ILL requests, the module may be used to manage document delivery requests for external users (e.g. companies) to whom requested material is to be delivered.

Integration

We identify here some examples of the key aspects of the way that the system is integrated :

Borrower data – all borrower information for requests comes from the main database – no separate keying of information is required.

Bibliographic data – as an outgoing request is entered into the system, a temporary catalogue record (which by definition wouldn't exist) is created; when the copy of the requested work is received, then a temporary item record is made which can be used to track the issue of the work to the requesting borrower.

Request processing is completely integrated into the regular processes within the library – for example, when an incoming request is accepted by the library, then it is a single operation to 'extend' the request so that it acts as a hold or a stack request, so that the normal library functions for retrieving books (e.g. hold shelfcheck messages) can be used to retrieve and dispatch the work to the requesting library.

Many of the input forms and screens, will have default values when being entered; and many fields are optional. If a library does not use an option available in the system, then the relevant data fields are simply not displayed or requested. In other words, it is possible to tailor the system to make it as ergonomic and user friendly as possible.

Delivery and receipt of the requests

The delivery and receipt of requests (as opposed to the works themselves) can be handled using a variety of mechanisms. The primary method is to use the ISOILL protocol (ISO 10160/10161) so that all requests and related transactions can be transmitted electronically between the requesting libraries.

But support is also provided for transmitting and receiving requests to and from systems which do not support the ISOILL protocol, e.g. by email or in hardcopy form. The mechanisms developed also allow for the electronic transmission of requests using methods other than ISOILL ( to a certain extend).

Other mechanisms for the automatic transmission and receipt of requests is also implemented, including the British Library ARTEmail mechanism, the PICA Email format and in a future release for Impala in Belgium.

Delivery and receipt of the work

The Interlibrary Loan module provides support for the transmission of electronic copies of the work, via variety of mechanisms, including via FTP.

Bibliographic enquiries

It is possible to configure the system to allow for enquiries from remote libraries using the systems Z3950 server processes. The Interlibrary Loan module itself allows for the configuration of profiles for searching for material on other library systems, not only to check the availability of the requested item but also to draw upon the bibliographic information to make sure that the data passed with the request is accurate and correct.

1.2 Workflows for outgoing requests[//]

The discussion below represents the main or expected workflow through the system.

The original request from a borrower may be entered using the ILL module "New" request input screens OR may be entered directly by the borrower via the WebOpac.

The initial status of the request is set to "Review" for Web created requests i.e. indicating that the request is to be checked by the library (and may be optionally set this way for staff input requests). Checks are be made on the borrower's status within the system to cater for blocks and so on in the usual way.

Bibliographic data entered will be saved to a catalogue record in a workfile, which may be accessed in the normal ways, but need never be directly retrieved in this way for the main ILL processing.

New requests may be checked against the main database(s) in case the borrower has mistakenly requested a work which is held by the library. Requests may, at any stage, be converted to normal reservations, or to purchase orders (and a reservation), if staff feel that it is appropriate to buy a copy of the book. Requests may, of course, be cancelled or rejected and appropriate messages relayed to the borrower e.g. via email or the WebOpac.

Staff may check the request against any appropriate system using the system's Z3950 client software to check for availability at a possible supplying library (for example, against COPAC) –appropriate searching profiles are fully configurable by the library. And it is possible to retrieve the bibliographic information to enhance what might be a rather brief or inaccurate request from the user.

Once a supplying library has been selected, and any other possible forwarding libraries added, the system will calculate charges accruing both to the library and independently to the borrower. Such charges may be a function of both the supplying library and the borrower category; in addition the system will allow for a borrower "quota" – a limit of the number of requests – at which point exceeding the quota may cause the rules for calculating the charges to vary.

Obviously, such information as whether the request is for a book or a copy, how the work is physically to be delivered (e.g. electronically, or by post etc.) can be entered, although much of this can be inferred by the system automatically.

When a request has been entered, it may be delivered immediately or at scheduled intervals to the supplying library. In particular, if the supplying library supports the protocol, then the message will be delivered using the ISOILL protocol, and in this event much of the interaction can be handled automatically by the system.

For messages handled by the ISOILL protocol, the system maintains a list of items requiring attention – for example, if the response to a request indicates that there is a special condition attached to the loan.

There is a well defined set of steps – responses / replies – for the ISOILL protocol which is handled by a simple "Action" button to allow users to respond as appropriate; for "manually" handled requests the relevant steps can be truncated without affecting the system logic.

For a photocopy, the request is marked as completed when the supplying library indicates the item is supplied; for books, the receipt of the item causes the system to create a temporary book barcode and the book can be issued in a single operation to the user. In some libraries, the book may be delivered to the ILL department; in this case a single key stroke allows a logical "hold" to be placed against the copy, and it could be shipped to a remote branch, for placing on the hold shelf for issue to the borrower in the regular way. The system is thoroughly integrated – so that the processing workflow for holds and ILL can be identical.

Requests for renewal of the item by the borrower are automatically fed into the ILL system, generating (subject to staff approval) a request for renewal being sent to the supplying library.

1.3 Workflow for incoming requests[//]

Requests from other libraries may be received via the ISOILL mechanism, in which case they will appear online immediately or may be entered manually.

The bibliographic data from the incoming request will be checked against the catalogue, to identify possible matches within the system. A request may be confirmed or, of course, refused; and it is possible via the ISOILL protocol to submit conditions on the potential loan back to the requesting library.

Once a local catalogue record has been associated with the request, then it is possible to "extend" the incoming request, so that it is treated like a normal reservation or stack request, with a pickup location, typically set to the ILL department.

When the item is made available at the location responsible for actually shipping the item, it can be issued to the requesting library, a shipping message sent to the library and labels printed all in a single operation.

A "dummy" borrower record is created for the requesting library and the loan appears in all other respects as a regular loan.

There are some differences in options, of course, for the two general sources of the request initially. For example, for an ISOILL request it is not permissible to edit the incoming bibliographic data (since it is THIS that they asked for), but of course you MUST be able to for manually entered requests !

Requests which cannot be supplied may be automatically forwarded to other libraries.

1.4 Display of requests[//]

The normal range of search keys and views is available – it is possible, to name just a few examples, to limit results to requests from a given library, to requests associated with a specific branch, to view requests which are all "pending" and so on.

Borrowers will be able to monitor the progress of their requests via the WebOpac under User activities.

2 Parameters[//]

The parameters for the Interlibrary Loan module are set in AFO 822. See the help of that AFO for more information.

The Interlibrary Loan module also uses mailmerge technology. See the general help on that subject for more information.

A brief overview of some concepts follows below.

2.1 ILL Departments [//]

The ILL department settings in AFO 822 define "your" organisational details. This is the organisation to which requests are sent and received. A single ILL department corresponds to a complete circulation metainstitution, but more than one department is allowed for each metainstitution. So, for example, a single ILL department may only process outgoing requests on behalf of borrowers registered with that metainstitution; however more than one ILL department may "manage" requests for that set of borrowers / items. Effectively, this means that from an external point of view the system may comprise multiple "libraries" to which requests can be sent; but once those requests arrive, to all intents and purposes, subsequent processing is indistinguishable.

2.2 ILL Libraries[//]

ILL libraries are the organizations to and from which requests may be sent and received. So with these settings in AFO 822 you define the details of other organizations.

Note

For BL and PICA, there are special formats for electronic delivery, using specially formatted emails. It is necessary to define the email server, passwords and so on in order to send the emails.

2.3 Consortial / Multi institution systems[//]

Supplier libraries are defined on a system-wide basis. This is required for technical reasons, in the way that the ISOILL protocol communicates with the system (at the point of receipt and delivery of such messages, the "meta-institution" is not an available setting). This is, of course, a desirable feature, since libraries need only be defined once on the system.

However, if there ARE multiple organisations using ILL, independently, then many settings above are "specific" to them. The parameter settings for libraries (on a single "form") are actually therefore a combination of some system wide settings AND some ILL department ones.

In brief the ISOILL technical fields are system wide – viz.

· Library code (e.g. RLG:TCDU)

· Library name

· Delivery type

· ISOILL email / IP address

· Suspend / until

· Web address

All other fields must be defined on a per ILL department basis.

The following should also be noted.

· The Z3950 search settings are defined on a system-wide basis (and related to settings in AFO 651). Since the library symbol is defined for the database, then ILL departments ought to ensure that they refer to the supplier with the same symbol.

· There will only be a single ISOILL database defined, which is therefore shared across multiple organisations. In general bibliographic searches for requests may therefore result in matches on requests for other organisations. Of course, users would NOT have privileges to amend such requests, but limited "read-only" access cannot be avoided.

· For technical reasons, all such library codes are available for selection and use at all the various places where it is necessary to select a supplier, BUT further processing of a request with such a supplier selected is suspended until the necessary ILL department specific settings are assigned.

3 Charge schemes[//]

This section outlines the general method for calculating the various types of charge within the module for Interlibrary loans. Since libraries calculate charges in a variety of different ways, the methods described below are potentially quite complex, and there may be several ways to achieve the same result. However, it is expected that for any one organisation the options used would be made up of just parts of the possible settings and would be simpler in practice than the general solution appears to be.

There are three different types of charge overall that need to be considered – how much does the library charge to supply material, how much does it charge its borrowers when requesting material from another library, how much does another library charge for supplying material.

3.1 Overview[//]

Charge schemes are a way of defining the rules for determining how a charge for a request should be calculated. As will be seen below, the fields which can be used to determine this are

· Whether the charge is for incoming or outgoing request

· The service type (Loan or Copy)

· The item type

· The number of pages for a copy

· Whether the charge is to be made to a departmental budget

· Whether the charge is for a borrower for which copyright charges apply

· The service level (normal, rush and so on).

· The borrower category

· Whether the borrower's quota has been exceeded

There may be any number of different charge schemes defined in the system.

Once a scheme has been set up, then it may be “attached” to a Library record – this then defines how charges are calculated for

· Lending items to that library

· Borrowing items from that library

· Calculating charges to a budget account / or

· Calculating charges for an individual borrower

So, for example, if the majority of the libraries that requests are exchanged with have the same policies have the same rules, then a single charge scheme may be defined and attached to all of these libraries. This means that only 1 set of rules need be defined AND changes to those rules can be applied as a single modification.

In practice, the system allows for considerable streamlining of the above.

3.2 Example[//]

Below is an example of what a detailed charge scheme could look like:

First of all, the display is separated into the four main constituent parts - so we have

· Supply the charges to be made for lending the item to another library

· Request the charges to be made to the library for borrowing an item

· Budget the charges to be made when a budget account is used

· Borrower the charges to be made to an individual borrower

Looking at the supply charges, we have a standard charge of 5.00 for loans. For a thesis, the charge is 7.00. For a photocopy, the charge is 7.00, PLUS an additional charge of 1.00 per page. If the number of pages is more than 10, then the additional charge is reduced to 0.80 per page.

The “per page” charge is always an additional amount, implied by the Page range field being set.

For borrowing, the charge is expected to be 15.00, except if copyright charges are payable in which case the charge will rise to 25.00. Copies will cost 10.00 plus 2.00 per page.

In this case, the library is very generous and the charges passed on to a department budget or individual borrower are much less. To a borrower (lines 16,18) the charges for a copy are only 3.50 + 0.50 per page; the exception is for an EXTERNAL borrower category for which a charge of 23.00 is made (plus 0.50 per page).

(Note also in the display that for the EXTERNAL borrower, the charge is shown as “13.00 / 2.00 EUR” – see the note on Admin fees below).

3.3 Method of determining the charge(s)[//]

When calculating the charge, the system looks at each and every rule defined for the “role” (i.e. for which type of charge we are calculating) to determine WHICH is the most appropriate rule to be used. It may be seen that there may be several rules appropriate – for example, when dealing with a copy for an EXTERNAL borrower, the system will see that rule 16 (3.50) applies, but then the later rule (18) also applies so the 23.00 is used.

There may be rules which apply in some combination of specific and general cases. Looking at lines 14 and 15, we see that the charge for a loan for an external borrower is 13.00, but for a thesis the charge is 9.00. In this case, what do we charge an external borrower for a thesis? The rule is to take the latest matching line , so the charge would be 9.00 (line 15 comes after line 14).

Rules can be moved up and down. In the previous case, it may be more appropriate to charge 13.00 so the “thesis” rule would be moved before the “EXTERNAL” rule (resulting in the EXTERNAL rule being found later, and therefore taken in preference!)

Admin Charge

When applying charges to a borrower or budget, the question arises as to exactly WHEN the charge is payable. Should it be charged (and become payable) when the request is placed ? But, then it may be that the library cannot find the item from its usual suppliers, and has to do an expensive extended search at, say, the British Library. Some libraries have a policy of charging borrowers regardless of whether the request is supplied or not.

The Admin charge may be added to the charge scheme as a fixed amount, payable immediately the request is placed. It is therefore conceived of as an “administrative fee” rather than as a charge for the request; libraries are of course able to decide whether or not to use this feature.

This charge becomes payable when the request is entered into the system – either by the borrower from the WebOpac or by staff. At this point, of course, a supplier may not have been selected, so the charge scheme used would be the default scheme – and in theory this admin charge is probably NOT related to a specific supplier. (And is therefore not quite a general part of the charge scheme structure)

However, in order to keep the rules in a single “place”, the Admin fee is tied in with the other charging rules i.e. within the charge scheme mechanism.

For some libraries, especially publics, it may be that only the Admin fee is defined i.e. they define pretty much a fixed amount for loans, regardless of other considerations.

In the summary listing of the rules, if an Admin charge is defined for the rule, then this appears as

/ 2.00 following the charge amount.

The Admin charge ONLY applies to charges to borrowers or budgets i.e. for outgoing requests only.

Other charges

The other charges command allows for two additional fields to be specified for this scheme. These are:

· Late return or lost fee: Charge made to the library on late return or if lost

· Refund: Refund made if a lost item returned.

These are a mechanism for storing such charges incurred by the library.

Charges by service level

The Charge by service level command allows ADDITIONAL charges to be added to the charge calculated as described above.

For any or all of these search levels, additional charges may be added by selecting the relevant line.

This brings up an input grid and workflow as for entering the main charges. This means that the rules for defining additional charges may also be very complex. In practice, it is expected that the rules entered at this level would be very simple e.g. just a simple setting for Loans and Copies only.

In other words, it is expected that the extra charges are rather simply defined; however if the library really wish to charge normal users an extra 2.00 for a rush request, but EXTERNAL readers 3.40 for such a request, then they can!

4 Budgets[//]

Charges for outgoing interlibrary loan requests may be charged to departmental budgets rather than being made payable by the individual requesting borrower (as can be seen in the description of Charge schemes above).

Whether a request is payable by the borrower or charged to a budget is set on an individual request (as described later) or may be presented as an option in the WebOpac when the borrower is placing their own request.

This section describes how budgets are maintained and used within the system. In the following “department” refers to an academic department. When the ILL department is referred to, the full “ILL department” will be written.

Budget codes used by the ILL system can be defined and maintained from the “ILL Budgets” option from the main menu of AFO 822.

Budgets are defined for the circulation metainstitution and may therefore be shared by multiple ILL departments.

Department setup

The department setup allows individual budgets to be linked to a department, as defined in AFO 482 (i.e. the borrower departments), and to define some processing to be associated with this department.

Again this is optional – and is used when the invoicing for requests is to be made to the Department rather than the individual budget.

Borrower categories setup

It is possible to configure the WebOpac to allow borrowers to select a budget code against which the charge should be made. Assuming this option in the OPAC is in use, then it may be valid only for certain borrower categories.

Budget field on the borrower record

AFO 482 has two fields in the Borrower definitions/Preferences group: ILL Budget status and ILL Budgets, which may be defined as fields for entry on the borrower record in the normal way.

The first field determines how or whether the selection of a budget is determined in the WebOpac. The second links this borrower to one or more budget codes.

5 Invoices[//]

This section deals with the handling of invoicing for ILL requests. We have, yet again, four different contexts to consider :

Recording invoices from supplying libraries for received material
Creating invoices to requesting libraries for supplied material
Invoices to individuals for outgoing requests
Invoices to departmental budgets for outgoing requests.

Individual borrower invoices

Charges arising from the requests are added to the normal display of charges in AFO 414, and are therefore payable from that part of the system, as for any other charge arising. Currently explicit invoices for reservation charges, requests and so on are NOT managed by the circulation system.

Recording invoices from supplying libraries.

Invoices from supplying libraries may NOT be entered to the system (in the way that the system allows invoices from book suppliers to be entered in full in the Acquisitions module, for example).

However, if the library wishes, then Invoices may be logged against the charges raised for individual requests. This may be used in SSP (for example) to find requests for a specific supplying library's invoices. An online indexed search by such invoice numbers is NOT possible.

Invoicing to departments and budgets

Invoices may be generated for all previously uninvoiced requests at any time using the Invoice processing option from the “Budgets” list. At the time of running, all such requests up to but not including the date of the run will be added to a single invoice.

Additionally noting the setting Group budget invoices by the department on the ILL department configuration, all the budgets linked to a department may be aggregated into a single invoice. (And if a budget is not linked to a department, then the set of requests associated with that budget will be aggregated in their own).

The format of the invoice numbering is defined for the ILL department (tab General)

5.1 Generating the invoices[//]

The Invoicing job is a standard “batch task” – it may be run online, in batch or as a regularly scheduled task in “memory”.

The basic processing is fairly straightforward.

For each ILL department on the system, the process will select all requests for which the payment is to be made to a budget account, which is ready for payment (i.e. payable) and obviously previously not invoiced.

The selection run will process requests up to but NOT including those entered “today” – to ensure that the “boundaries” of the invoice are clear - that is, for a given day, requests will not be invoiced across multiple invoices (for one budget).

Separate invoices are then generated for each budget, totalling the individual requests for that budget code, or are aggregated according to the “Group by department” setting.

Invoice numbers will be allocated according to a setting for each department.

For example,

Format for invoice numbering : Inv.2007/99999999

which would generate invoice numbers “Inv.2007/0000001”, “Inv.2007/0000002” and so on. A running invoice sequence number will be maintained by the system, so that the 999999 portion is always unique.

5.2 Printing the invoices[//]

The invoices themselves are physically printed using the mailmerge processing (see the general help on mailmerge).

The master document (i.e. the document which defines the layout of the invoice) can be defined for the Budget code or for the Department in the Department setup option. (NB Department here being the organizational department, not ILL department).

If the requests were grouped, then the layout used is that defined for the department grouping, otherwise for the budget.

As touched on above, in theory the system will allow some budgets to be grouped and others not – in which case, the invoices will be a mixture of budget specific or grouped invoices.

The following is a screen image of an example invoice master document

5.3 Invoicing requesting libraries[//]

The following sections describe how requesting libraries may be invoiced.

Since this processing is concerned with the external libraries, the processing is initiated from the “ILL Libraries” option in AFO 822.

The workflow is almost identical to that for budgets.

5.4 Generation of the invoices for incoming requests[//]

The way that the invoices are created is, however, significantly different. It is the “Payment method” assigned to each request that is the key parameter in deciding how invoices are selected and generated.

The payment method is defined by default for each library. This is the default value assigned to each request – although it may be modified for requests individually.

The payment method is meant to indicate HOW charging between the libraries is carried out. Standard settings are “Voucher”, “Prepaid”, “IFM”, “Invoice” and so on. The ILL department may configure their own settings.

The invoice generation uses the “Payment method” as a primary key for generating invoices. A single invoice is therefore a selection of previously uninvoiced requests for a given payment method. Typically an invoice will be for a given library, but this can be modified as explained below.

“Invoices” in this context is then really a selection of ILL requests – the system will create such selections for all requests. In some cases, the supply of an item will be to a library where there is a cross totalling of requests e.g. in some kind of consortium. (A typical example is where the request has been mediated by the British Library).

In this latter case, the consortium (the British Library) balances the incoming and outgoing requests to come up with a final “balance”.

The system will STILL generate “invoices” but in this case it can be seen as simply a statement of supplied requests rather than an actual invoice to be send and totalled to requesting libraries. Whether the output from the system is an actual invoice simply depends on how the ILL department chooses to layout and use the resulting output.

The payment method therefore determines two main functions :

The first is that the actual output format of the notional invoice must be defined for each payment method. The physical formatting of the invoice is (as above) handled by a mailmerge process. For a payment method where this reflects a true invoice, then the output would be laid out as an invoice with charges, totals and so on.

Where this invoice is really just a “listing” of requests, then it may be more appropriate to simply list brief details of each request for that payment method.

The second option is that, in the above example for the British Library, we do NOT select for individual libraries. For requests marked with “payment method”, say, “BL” then we can tell the system that the invoicing run is for all requests with that payment method. We do NOT separate out the requests for different libraries into separate physical outputs.
Note that the pseudo invoice layout is therefore defined for the payment method – not for the libraries – and this implies that any “billing” address must comprise part of the master template.

Finally, when the Invoice generation function is started, an initial dialogue offers an input form. This allows for a selection by payment method when the invoice generation is carried out. Typically, it is expected that invoicing would be carried out automatically at certain times of the month, so it is possible to initiate separate runs of invoicing based on the payment type. For example, we might select requests with a payment method of “RegularInvoice” to be run on the 1^st of the month, but for the “BL” method, this is only run manually on occasion.

It should be noted that this allows for certain Payment methods to be exclude completely from the invoice processing. That is, if no run ever selects them, then no invoices will be generated.

5.5 Summary of invoice master documents[//]

We have two sets of invoices – those that are internal i.e. charging “our” borrowers for their outgoing requests, and those to external libraries i.e. for incoming requests. These can be further broken down as follows, describing where the layout is defined.

Outgoing requests

· To individual borrowers Not handled by the ILL processing, but via AFO 431

· To departments This is defined for each department.

· To budgets Defined for each budget

Incoming requests

· Grouped by payment method

· Individually to each library by payment type and billing address

The layout for the departments is defined in AFO 822 - ILL Budgets - Department setup.

For individual budgets the layout is defined for each budget.

For invoices for outgoing requests, the layout is defined according to payment type from AFO 822 - General options - Payment types

The layout is always defined for each payment type and never dependent on the requesting library (apart from multilingual considerations!).

Finally, note that although the definition is as above – there is no reason why settings should NOT share the same master document path name.

5.6 Examples[//]

The following are two adapted outputs from a library. These examples are intended to further clarify the concept of “pseudo invoice” discussed above.

For Requests coming from the libraries in the UK, there are really two methods to claim the charges due. The request may have come directly from the library (although this would be unusual) or it may have been mediated via the British Library.

If mediated via the British Library, then we assume that the payment type was set in the request as “BL”; for directly received requests, then the payment type is “INVOICE”. (Noting that these are library assigned settings).

The settings might then be

Payment type	Output format	Combine all libraries
BL	BriefListingTemplate.doc	YES
INVOICE	InvoiceFormatTemplate.doc	NO

Let's consider where we have the following requests from library code “16-12345” and from “16-9876”

Request	Library	Payment type	Amount
R1234	16-12345	BL	6.50
R4567	16-12345	BL	6.50
R9876	16-12345	INVOICE	4.00
G934349	16-9876	BL	6.50

The two outputs look something like

i.e. all the requests with Payment type BL appear on this “pseudo” invoice. Really it is just a statement, of course.

This layout corresponds to the “BriefListingTemplate.doc” (in the Payment type setting)

For the INVOICE one we might have

This layout corresponds to the “InvoiceFormatTemplate.doc” defined for the “INVOICE” payment type.

6 Notice Production[//]

A whole range of notices are available to send to both suppliers, requesters and local clients. For ISOILL libraries such "notices" are delivered automatically and electronically according to the ISOILL protocol, but for other libraries such notices must be generated as textual items.

In addition to notices, the system can also output mailing labels, insert slips and so on.

There are really then three main sets of notices

· Notices to other libraries

· Notices to clients

· Outputs for processing purposes i.e. for the ILL department

Notices to other libraries include the original request, general messages, cancellation requests, overdues, recalls and so on – there are 27 different types of notice available.

Internal outputs include a variety of mailing labels, insert slips and so on.

Notices to borrowers include availability notices, cancellation notices, status reports.

The actual layouts used can be defined for each library, if required. For example, for requests to North American libraries, the ALA request form might be appropriate, whilst for other international requests the IFLA form would be more suitable.

Layouts can also be defined in the contact language of the library e.g. to send requests worded in Welsh to a Welsh library .

In order to avoid having to enter the layouts individually for (say) 27 notices for each library, or to define them individually for each ILL department, the system groups notices together into “Notice sets”. The set of notices can then be linked to a library – there may then be two or three different sets defined which can be applied according to the type of library.

There are therefore 3 distinct categories of Notice set …

· Sets for libraries

· Sets for the ILL departments

· Sets for the borrower.

Finally there is a fourth category – for cancellation notices – so that the wording of the notice can be tailored precisely to the reason for cancelling a request.

6.1 Notices to clients[//]

In general, the status of a request will be available to a client via the WebOpac. The sending of a 'printable' notice about some particular event in the lifecycle of an outgoing request is therefore simply a matter of policy for the ILL department. It would be expected that an explicit notice about the arrival of an item, for example, WOULD be sent to a client, but the fact that it has been shipped by the supplying library would typically not be sent.

The notices to be sent and the way that they are sent is defined for each request, according to a "contact method" setting, although the choice of sending a specific notice is sometimes a function of the type of notice. For example: cancellation of an outgoing request – in this case, if the cancellation of the request is at the borrower's demand then there is no point in sending them a cancellation notice!

Ad-hoc notices may also be sent to clients, either as email or printed notices.

Sending a notice to a client may be initiated in one of the following ways :

· When a request is cancelled, a "reason" may be assigned to the cancellation. For each reason a notice format may be associated. When the cancellation is entered, then staff have the option to send a notice to the client.

· When a request is marked as "unable to supply", then again a notice code is associated, and staff have the option to send a notice.

· At any time, an ad-hoc notice may be selected from any valid notice type.

· When a request is marked as supplied, manually, again staff may choose to send a notice.

Of course, on receipt of an item, it is possible for the system to automatically send a "request available" notice to the client.

It should be noted that such notices may be sent at any time. A history of notices sent is recorded by the system, but a previously sent notice MAY be printed under all circumstances (typically for reprinting, of course); a warning will be given if a previously selected notice is chosen.

6.2 Physical production of notices[//]

Notices to clients may be printed immediately or may be "selected" but actually output as a separate process. Printing is always to a printer available to the PC on which the client is running, and may be a local or networked printer (i.e. as is usual for all such printing).

The above specifications talk about a "notice code" for notices. This is really the name of a Mailmerge template. This notice handling is described in other documentation (See also the general help on mailmerge), but the following outlines the process.

When one or more notices are required, the system creates a file with ALL the possible fields (q.v.) and sends this file and the name of the template to the client. This automatically runs a mail-merge to merge the data fields and the template to create an output file. The output file can be automatically printed; it can be automatically emailed or it can be simply "left" on the screen for possible editing by the current user (presumably for subsequent printing, emailing or even saving).

A template might look like

The text inside {}s is automatically replaced by the data pertaining to the specific request. It is emphasised that this is a Mailmrege master document file and the full features of word processing are available to make notices both elegant and appropriate to the context of the library.

A full set of example templates is provided with the system (e.g. one for each of the standardly supplied cancellation reasons, one for each of the "not supplied" reasons).

Notices to Supplying or requesting libraries

Notices to requesting are sent automatically for ISOILL libraries for most types of notice.

For non-ISOILL libraries, the following notices are available. For each type of notice, the required format (Word template) may be define on a per supplier basis. If no format is defined, then no such notice will be generated.

Several notice types are only generated if the appropriate "action" is manually initiated for the request – for example, it is in principle possible to send a notice to tell the requesting library that you will supply the item, but this is only available IF staff go to the trouble of initiating such an event / action.

Some of these notices correspond to the ISOILL messages sent; in practice for manual requests, this full range of notices is unlikely to be used. We would also expect these to be sent when the actual method of sending the notice is by email; hardcopy is less likely. Nevertheless, these are all options for the library to use or not as they wish.

In addition, for ISOILL libraries, it is also possible to send "messages" in printed or email form. Normally, these would be sent by the protocol but this is an additional option (e.g. in the event that there is some problem with their ISOILL processing!).

As for clients' notices, the actual output mechanism is via Mailmerge processing, and according to context, notices may be generated individually or as a batch process.

Additional outputs are Supply and Return labels for the actual shipping of loan items.

6.3 Notice Printing[//]

For those notices which have been selected but not printed (or emailed) there and then, a separate menu option displays a list of the different notice types to be output.

(This is comparable to AFO 452 in the sense that the possible notices required for printing/emailing are displayed grouped according to type of notice).

Since these are generated on an ad-hoc basis (i.e. specifically for each request, as described below) at any one time, the list displayed is for all outstanding notices. If they aren't output, then the list just grows.

At any time (as described below) a specific type of output may be generated for individual requests. However, once a set of notices are printed (i.e. sent for actual output), then these are grouped together and kept for a library defined period so that they can be reprinted in bulk (for example, if the printer was actually misprinting for some reason).

Specific sets of such outputs may be selected – both on regular and reprinting. Criteria for selection include a date and time range (based on the time that the action causing the notice to be required was entered); the specific output format required (i.e. the Word template code); the responder library. It may also be based on outputting a simple range of entries – e.g. "output records 1-50" (although this is not entirely straightforward – at time of selection, the system simply cannot correlate this to pages output and so on (since this is a complex function of the Word processing)).

6.4 Notice Sets[//]

The set of notices may be a function of either the department or the remote library, according to the type of notice. The notice set selection firstly asks which type of set is to be managed:

· Departments

· Libraries

· Borrowers

· Cancellations

This leads to a list of the different notice sets defined.

Selection of a set then leads to a listing of the different types of notice available.

Some general points can be made

If no “master document” is defined, then this implies, of course, that the output is simply not required.

For the Department labels, the system offers a choice of printing insert slips or mailing labels at the point of supplying, receiving or returning a title. We allow several “flavours” of such labels – if more than one of “Label type A” , “Label type B” and so on are defined, then the user is offered a choice of which type of label is most appropriate for, say, the package output or the size of the document being received. Another example might be that we need different labels when returning items overseas as opposed to locally.

6.5 Stored outputs[//]

Any prints NOT printed immediately are put into a “deferred print” queue. Similarly outputs generated by “overnight” processing e.g. overdues are also generated automatically but then queued up for physical printing.

These may be found from the “Deferred prints” option from AFO 821

7 Functional processing[//]

The Interlibrary loan processing is carried out from a single AFO 821. This leads to a menu with three main options.

· Alerts

· Incoming requests

· Outgoing requests

In general Incoming and Outgoing requests are managed independently, although there is a single place “Alerts” where events indicate that some action is required (for either incoming or outgoing request).

7.1 Incoming requests[//]

The incoming requests screen displays a summary of the incoming requests broken down by the status of each request.

From this screen, selection of a line leads to a list of the requests with this status.

7.2 Outgoing requests[//]

The same type of summary display is shown. The list of possible statuses is slightly different, but subsequent processing options are the same.

As for incoming requests, the Insert icon may be used when staff wish to add a new request manually. (Typically, hopefully, borrowers will use the WebOpac to add requests but if not then this route is the mechanism for adding a request).

7.3 Searching for a request[//]

A specific request may be searched for either by the bibliographic information within the request, or by various other keys pertaining to the request.

These may be initiated from the summary display shown as the primary display for the ILL functions (as above).

Bibliographic searching

A search for the bibliographic data is carried out using the regular Vubis search processing, for example as used to place a regular reservation.

The following points should be noted.

The bibliographic data for outgoing requests is held in a separate database, installed by the installation options described previously, together with its own indexes. However, in a transient way, it is possible to link an outgoing request to a record in the system's main database(s) – in the situation that a borrower has failed to recognize that the library has a copy of the requested title.

Incoming requests will be stored in the special request database AND, when the match between the request and the local databases has been made, then they will also be indexed against records in the main database.

A search from this AFO will always apply a special filter – i.e. it will only retrieve matches for which there IS an interlibrary loan request.

Having found a suitable bibliographic record, the user must select the “Choose record” option from the full display, which will then lead to a summary display of the requests attached to this title.

Request searching

It is also possible to search for specific requests by:

· Search term is the expression to be used for the search

· Search type offers a dropdown list of the three types

The following fields allow the search to be further qualified.

· Status offers this dropdown list of possible requests statuses. The STATUS selection applies to the request as a whole.

· Incoming / Outgoing requests

These two settings allow the user to limit the search to the specified type of request.

· Dates This set of four fields allows the user to define a date range – based on a specific type of date from the request.

· Limit search to current transactions: The “Limit search” option tells the system whether to look only at the latest such transaction or whether to check through the “history” of the request. If not checked, for example, then a search on “Not supplied date” would find a request which might be “supplied” but which was “not supplied” at some point in its lifecycle. (Clearly some selections imply the latest transaction e.g. Supplied date).

8 Request Display[//]

The result of a search, selecting a request and so on leads to the display of a single ILL request.

The request display is shown on a single "tabbed" form, with each section displaying the details of a particular section.

The form itself has a number of command buttons to initiate specific actions.

The sections of the form are

· General Data related to the internal processing of the request

· Bibliographic Bibliographic data for the request

· Request Source Original request details

· Additional Additional information for identifying the requested work

· Client Borrower information

· Requester Specific information about requesting library

· Supplier Specific information for supply library

· Delivery Delivery information

· Charging Information on associated charges and costs

Precise details of what is ON the form depend on the type of request, how far is has been processed through its life-cycle and on whether it was an ISOILL request, or manually entered.

9 Interlibrary loan background processing[//]

The ILL daemon is initiated once by the Nightwatchman, but once started continues to run independently of the Nightwatchman processing. When set to run in memory (i.e. as a regular job) a "close down" time would normally be set. This allows the process to be stopped automatically, late at night so that backups etc can be taken in the knowledge that no updates (from this source at least) are being made to the database.

Subsequently the job would be scheduled to start-up every day very early in the morning – and then it continues all day.

The frequency and shut down times are set in the General options for the ILL module. Note that there is a single daemon process which runs for all metainstitutions and departments.

This process carries out two main tasks initially

· Miscellaneous jobs – “Housekeeping” - on the system

· Generates the daily notices

It then continues to run at the frequency defined to check for:

· Incoming ISOILL messages

· Incoming messages from the British Library

· Incoming messages from PICA.

This task is initiated from AFO 822.

9.1 Housekeeping[//]

Requests that are completed or cancelled remain visible from the borrower record (e.g. from AFO431) temporarily. The housekeeping deletes the link so that only “active” requests are usually seen.

Requests that have been returned or copies supplied are also retained temporarily in the “returned” and “supplied” summary lists. The housekeeping moves these on to the completed lists.

9.2 Notice generation[//]

This carries out essentially four main jobs

· The generation of overdue notices

· The generation of expired notices

· Generation of certain types of alert

· Generation of chasers

9.3 Overdue – received items[//]

There are two system wide settings which pertain here.

a. Show overdue items in the alert state when how many days overdue ?

b. Refresh the alert state for overdue items how often ?

Any items which have not been returned by the due date (plus the setting in a.) will be displayed in the alerts screen. Setting a. may be negative – in order to show such items BEFORE they become overdue.

It is possible to drop such requests from the alert state manually (e.g. to indicate that they ARE being dealt with), but they will reappear every so often according to the setting in option b. (So, for example, if they are still due for return after another week, then a reminder will be generated).

In addition, for ISOILL requests, any automatically received "overdue" message will push the request into the Alert state.

Of course, the main reason for an item being overdue is that the client has not returned it. Overdue notices to the client are handled by the regular overdue processing for loans, within the circulation system.

9.4 Overdues – supplied items[//]

The generation of overdues to requesting libraries is handled on a individual supplier basis, or, if not specified, according to the same default settings for the ILL department according to the following settings, against the library.

As for received items, it is possible to highlight overdue supplied requests after a given period (possibly negative) in the Alerts display.

It is possible to send up to two overdue notices automatically, according to the intervals defined in the settings. It is possible to define shorter intervals for items that the library has recalled.

It is possible to assign items as "very overdue", which will make them reappear in the Alerts list, and to be shown separately in the summary display of requests.

For the notices, an output method is defined for each type. This may be one of ISOILL, Email or Print. This defines the actual method to be used for the overdue. Normally this would be set to ISOILL for ISOILL libraries, but can be overwritten i.e. the library can force the notice to be printed or emailed separately.
If either ISOILL or Email is specified and this is not possible (not an ISOILL request, no email address available), then the notice will be printed.

The setting and processing of items as 'overdue'; according to these parameters is carried out by a Nightwatchman job, in the usual way.

10 Processing of Expiry messages[//]

Requests may be considered to “expire” under two main circumstances

· When an explicit expiry date or “needed by” date is passed

· When a condition is set with a specific reply by date.

It is easiest to consider the processing separately for each of these situations, further subdivided by whether the request is incoming or outgoing.

10.1 Incoming requests[//]

Expiry date

If the expiry date is set or needed by date is set (or whichever is the earlier if both), then the system will generate an “Expiry” message. This will be sent using the ISOILL mechanism (when that is the mechanism used to communicate the request) or, if a notice layout has been defined for the requesting library's notice set, then an expiry letter will be created (for subsequent printing or email).

The request must have a status of “Pending”, “Inprocess” or “Conditions” for this to apply; once the item has been supplied then obviously the expiry date no longer applies.

Conditions

If the status of the request is “Conditions”, then this means that the local library has applied some conditions to satisfying the loan. It is possible to set a date by which the requesting library must respond. If this is passed, then an expiry message is sent (by ISOILL or by letter/email). A different layout of notice is available so that this can be distinguished from the regular expiry notice.

Once an incoming request is expired, then it is moved into the “rejected” summary list; and this terminates the transaction.

Expiry alerts

For regular expiry messages, a setting for the department will allow requests which are ABOUT to expire to appear in the Alerts listing. This allows the ILL department a chance to perhaps make one final effort to satisfy the request.

10.2 Outgoing requests[//]

Expiry date

For outgoing requests no message is sent automatically – for ISOILL, it is expected that the responding library (or intermediary) would send an Expiry message. In addition, although this may terminate the request with the current library, it may be that the request should be forwarded to another library.

In this case, the system will put the request into the Alert list, as an expired alert, but this does not affect the overall status of the request. The request may then be selected from the list and a cancellation notice sent to the (non)supplying library – but this is a manually initiated task. The cancellation processing then offers the chance to forward the request.

Conditional reply

In this case, the supplying library is waiting for the ILL department to respond. If no response is made, then presumably the responding library will terminate the request.

The system will therefore re-add the request to the Alerts list for conditional reply at a period just before the reply date, according to a setting for the department. If no action is taken, then when the conditional reply-by date is reached, the request will be treated as for the regular expiry date processing above.

11 WebOpac considerations[//]

There are several aspects of Interlibrary loan concerning the WebOpac. These are

· The display to a borrower of their ILL requests

· To allow a "blank" template for borrowers to enter a request

· The consideration of electronic signatures and copyright issues

· The display of requests from requesting and supplying libraries

11.1 Display of ILL requests[//]

An option in the “User activities” setup in preferences allows for the option to let users display their interlibrary loan requests.

Requests are displayed in rows rather than columns (as, for example, reservations).

There are a number of options to determine what may or may not be offered to the user.

The various options are offered as command buttons below the request – for example

The “Days to show” settings tell the system whether to include, say, cancelled requests in this display. For example, it would be sensible to show cancelled requests for a few days as a “positive” confirmation that the request has been cancelled, but perhaps after a few weeks it would no longer be helpful.

11.2 Entering a request[//]

It is possible to allow specific categories of borrower to enter their own requests. Entering a request involves three main steps

· Identifying whether the request is for a loan or a copy of a title

· Entering the bibliographic data for the request

· Specifying how they would like the request to be processed

Each of these phases can be configured according to the WebOpac profile, of course AND for each borrower category. For example, it may be helpful to keep the options simple for undergraduates but to allow much more complex options or details to be specified for academic staff who use the ILL system more frequently.

11.3 General display setup[//]

The first step is to add one or more templates to define what bibliographic fields the user will be asked to enter; and to define “profiles” which determine what subsequent processing options are offered to the user.

These settings are defined for the system as a whole; specific templates and profiles may THEN be linked to the Web profile and to the borrower category

Next, there are the templates for the bibliographic data, comprised of several sections.

· The first section allows you to add some introductory and trailing textual fields

· The second section allows you to define which fields are mandatory

· The third section defines which fields are offered for the user to complete

11.4 Processing profiles setup[//]

The processing profile defines what choices are then offered to the user – e.g. can they request a delivery priority, can they choose to charge the request to a departmental budget and so on.

The profile is loosely broken down into 6 main sections:

· Introduction

· Departmental information

· Contact information

· Delivery

· Miscellaneous

· Charging options

Not all of these are, of course, required and each of these sections offer a number of subsequent options. They are aimed at representing the various methods and policies in use in many different libraries.

11.5 Examples[//]

Below are various examples of entering and display of WebOpac requests.

11.5.1 Entering request[//]

Initial screen

The initial screen asks whether this request is for a copy or a loan

11.5.2 Display of requests to libraries[//]

If the library chooses to allow it, then it is possible for a requesting library to look at their requests on the local system. Since there is a “borrower” record for the requesting library, then the system will retrieve the requests for that library.

The presentation is similar to that for the local borrowers but the wording and displays are adjusted to suit.

12 Circulation of received material[//]

The item will be issued for the loan period based on the regular loan rules. However, the system will ensure that the due date is less than the due date attached to the supply of the request.

13 Document delivery[//]

The interlibrary loan module provides support for the document delivery function. This process sits somewhere between the management of incoming requests and outgoing requests. For document delivery we are concerned with the supply of library material externally to library users – typically corporate organizations e.g. when the library supplies material to, say, a law firm.

This is often managed by an interlibrary loan department, and so falls into the general management functions of interlibrary loan.

It is similar to an incoming request

· The request is for the supply of a loan or a copy of a work or article from the library's holdings.

· It is necessary to ship the material either by mail or some kind of delivery service, or to send a copy electronically, perhaps of a single article of a journal.

· The material is returned in the same way i.e. not returned by the borrower in person to the library.

· Invoicing for the request is typically managed by invoice, externally from the main circulation system

It is similar to an outgoing request

· The supply is to a member of the library

Although a regular issue of the title to the borrower might handle the basic functions, it does not support the supply of a copy of a work; nor is there a mechanism in the more traditional circulation functions to allow the system to record the full details of the request, the fact that a copy rather than a loan is required and so on.

13.1 Settings relevant to document delivery[//]

There is a general system setting which can be used to “hide” the document delivery options in AFO 822.

Requests can be entered as document delivery requests on the staff side (and other ways are described below). In particular it is possible to offer this function to specific categories of borrower from the WebOpac.

13.2 From the WebOpac[//]

If the option is in use, then the command option “Document delivery request” appears on a selected title e.g.

If selected by a borrower without permissions, then a warning message appears.

Otherwise, the placing of the request continues in the same way as placing a regular interlibrary loan request. In the preferences section, there is a separate set of parameters for Document delivery – so a different template may be offered and a different processing profile.

When the bibliographic template is offered, then this is prepopulated with the bibliographic details from the selected record; however additional details may be added, particularly for copies of articles to be able to specify pages, and so on.

13.3 Online functions[//]

Document delivery requests appear in the “Incoming” section of the displays in AFO 821, since they have most in common with regular incoming requests (In most circumstance, the requester can be considered as an external library).

The request displayed is almost the same as for an incoming request, but the “Requester” tab is replaced by the “Client” tab from an outgoing request.

This is almost identical to that for an outgoing request but it should be noted that some of the settings which would have been logged against the requesting library are now on the client tab – specifically, the service type and service level.

13.3.1 Adding a document delivery request from the staff functions[//]

When adding a new incoming request, it may be changed to a document delivery request by using the Change command. This prompts for a confirmation.

This may only be used when the request is being created initially; once added an incoming request may NOT be changed.

13.3.2 Changing an outgoing request to a document delivery request[//]

If an outgoing request has been entered – for example, typically from the WebOpac, then it may be that it is determined that this is for material which the library holds.

As documented above it is possible to change this request to a regular reservation; however for the borrower categories for which this is permissible, it may ALSO be changed to a document delivery request.

Effectively, the processing of the request continues as for an outgoing request i.e. it is FOR one of the library's borrowers but it may be changed to a document delivery, which then affects the various options relevant.

13.3.3 Online processing[//]

The various commands available for a document delivery request are more or less the same as for an outgoing request (as if it had already been received) … so for example, the “Receive” option is never offered – this makes no sense. Similarly the “Return” option never appears – when the item is returned by the borrower then this completes the request.

Similarly, fields such as the “delivery” address no longer appear for a supplying library but are rather taken from the borrower's circulation record.

14 Testing the ISOILL protocol[//]

A test function is available from AFO 821. This may be used to both test that the ISOILL configuration is working and allows some simple messages to be sent backwards and forwards to allow for training of the use of ISOILL in the system.

The test function allows you to send a request, and subsequent dialogue, to a library added to the system as “INFOR:TEST”. It is also possible to send requests FROM INFOR:TEST to the ILL department, thus allowing for training of how these messages are seen.

Such requests are sent via the full protocol i.e. are sent out of the system (and back in again) via the full email server, and therefore provide a good test of the system, and particularly that the configuration is working.

Please contact the helpdesk for assistance to set this up.

15 Example scenario's[//]

Below is an example of how ILL requests could be set up for a particular library. This is done based on a series of questions. Separate examples are given for incoming an outgoing requests.